Increasingly, the people cost of managing IT infrastructure has become a dominant cost element in a customer's enterprise IT budget. In the case of database systems, people cost is significantly influenced by the number of database instances the IT organization has to manage. The term, database instance is typically used to describe a complete database environment, including the RDBMS software, table structure, stored procedures and other functionality. The term is most commonly used when administrators describe multiple instances of the same database. In an IT organization, database instances have hardware infrastructure needs (CPU, memory, disk space, etc.) that add additional costs. There may be many scenarios where an IT organization might be able to realize significant savings if the organization was able to run their workload with a greatly reduced number of database instances.
For example, FIG. 1 is an illustrative represent of a prior art database system 100 employing multiple database instances 104 of database 102. As may be appreciated, customers may deploy numerous test and development database instances 104. Often, these systems are shared by multiple developers or testers, and also by multiple independent projects (i.e. user 108). If a given project or projects are going to make disruptive database schema changes to database objects shared across projects, the database administrator (DBA) is forced to create a different database instance for each project in order to prevent the disruptive schema changes from impacting other users of the development or test system thus potentially creating many database instances.
In addition, when customers create shared test systems, they typically do not grant any special administrative privileges to the individual developers on that system, since the developer might misuse those privileges and impact the other developers that run on that same database system. This issue makes it difficult to deploy some of the more advanced application development and tuning solutions—solutions which can help the developer automate many activities such as: creating tables and indexes, tuning SQL queries, testing out database server SQL hints, comparing database access paths from one system to another, etc. However, developers generally can't exploit these solutions because they don't have the required database security privileges on the shared test system.
Furthermore, cloud computing is currently a hot topic. For database systems, the concept behind cloud computing is that a cloud provider can provide database services to applications and end users by deploying virtualized database instances on demand. FIG. 2 is an illustrative representation of a prior art cloud computing system 200 employing multiple database instances 202 of a database cloud 206. With current technology, database cloud computing often requires a unique physical instance 202 for each cloud user group 204 so that the different cloud user groups can be isolated from one another. If a cloud provider has to take this approach, it will be relatively expensive to support large numbers of cloud user groups, since the infrastructure requirements for a full database instance (even when virtualized) are high.
Still further, SAP™ offers an option to consolidate databases for multiple SAP™ components called multiple components—one database (MCOD). MCOD can significantly reduce the number of required database instances resulting in savings across the board. However, many current database management systems (DBMSs) do not generally have appropriate support for MCOD. Namely, once multiple components share the same database they lose ability to be efficiently individually backed-up, recovered, cloned, etc. This is a major obstacle for wider use of MCOD. As such, the actual exploitation of this useful option remains limited.